Tuning your environment for both X and dumb terminals

By Al Alexander

Does your site use both dumb terminals and X terminals with CDE? Are you always changing your PATH, your tty parameters, etc.? If so, you can do a little tuning on your startup files to greatly simplify your environment. In this article, we’ll explore the interaction between the CDE startup file, .dtprofile, and your shell’s startup file, .profile, for the Bourne and Korn shell or .login for the C shell.

The CDE startup file

The first time you log in to CDE, it automatically creates a default .dtprofile file for you. It places the .dtprofile file in your $HOME directory. Each time you log in to a CDE session, it reads and processes the commands in your .dtprofile file. It makes certain environment variables available to all your desktop applications. The .dtprofile file uses the Korn shell command syntax, so if you’re comfortable with the Korn shell, the .dtprofile file is easy to work with.

One simple thing you can do is to define the values of specific environment variables within your .dtprofile file. Since a command-line login never reads your .dtprofile file, you don’t have to worry about CDE-specific items interfering with command-line-specific items. Because the CDE reads the .dtprofile file only after you log in, you need to log out of the CDE and back in again to test any changes in your .dtprofile file.

The shell startup file

When you do a command-line login, your shell never looks at the .dtprofile file. Instead, it uses your shell’s login file, either .profile for the Bourne or Korn shell or .login for the C shell. Many people customize their shell’s startup file to customize their path, set terminal preferences, create aliases for commands and directories, and many other things.

The hurdles

Obviously, you’re going to have differences between your CDE and command-line login environments. However, in most situations you’ll want to keep some things the same. When you do so, you’ll find that trying to keep both the .dtprofile file and your shell’s startup file synchronized can be a tedious chore. If you change your preferences for the PATH variable in one startup file, you may have to make the same changes to the other startup file.

For example, if you install some GNU tools on your system, you’ll want both the CDE sessions and your command-line sessions to be able to access them. So, you’ll need to update the path in both your .dtprofile file and your shell’s start-up file. You’ll need to keep other types of data in sync between CDE and command-line sessions.

The tedium and potential for error are obvious. Every time you change .profile, you must decide whether you want the same changes reflected in .dtprofile. If so, you need to cut and paste the changes to your .dtprofile file. You also need to be sure that you put the changes in the right place. Then you need to test both your command-line login as well as your CDE login to make sure you made the changes correctly. And that’s just for the Korn shell.

If you’re using the Bourne shell, you may encounter some subtle syntax differences between the .profile and .dtprofile files. So when you cut and paste, carefully examine the text you’re moving to make sure that you’re not going to create any errors.

It’s even worse for the C shell. The syntax is so different that you can’t cut and paste between .dtprofile and .login, except maybe for comments.

A much simpler way

The people who created CDE realized that this was going to be a problem, so they created a simpler way for you to customize your environment and keep things synchronized. Rather than put all your customizations in .dtprofile and in your shell’s startup files, you can tell CDE to read your shell’s startup files after it reads .dtprofile. You can do this by setting the new CDE variable DTSOURCEPROFILE to true in .dtprofile.

When this new variable is true, it tells CDE to also read your .profile (or to read the .login file if you’re using the C shell). This way, you can put all your environment customizations in the same file. And if you’re using the Bourne or C shell, you don’t have to worry about the nuances of the Korn-shell syntax. Now you can manipulate all your environment variables, aliases, custom functions, paths, etc., in the same place.

Keeping the CDE and command-line login differences

This approach has potential drawbacks, however. In using this option, you must be careful that the commands in your shell’s startup file don’t try to set terminal options (tset, tput, etc.), write output to your terminal, or read input from your terminal when you’re performing a CDE login. Because the CDE startup process reads .dtprofile (and now .profile or .login) before defining or opening a terminal window, an erroneous command in your startup file can cause your CDE login process to abort or hang.

You can get around this problem by making your startup file a little smarter. The solution is to make sure you run any terminal-related or I/O-generating commands only when you’re not in a CDE login. To do so, you can create an if statement to keep separate all the things you want done only in a CDE window from things you want done only in a command-line login. The CDE environment helps this process along by defining the environment variable DT. If you find that DT is set, you can be sure that you’re logging into a CDE session. If, on the other hand, it isn’t set, you can be sure that you’re in a command-line login. Figure A shows a part of a .profile file that contains an if statement as described.

Figure A: Testing the DT variable lets you keep CDE and command-line login environment customization separate.

# Commands that may run in both CDE and
# command line logins:
PATH=/usr/bin:/usr/local/bin:/usr/ucb:/etc
MANPATH=/usr/man:/usr/local/man

if [ ! "$DT" ]; then
  # Commands that should run only during
  # a command-line login
  echo "Enter your terminal type: \c"
  read termType
  export TERM=$termType
  stty erase '^H' intr '^C' start '^Q' stop '^S'
  tput init
  tput clear
  echo "Hello again, Marco!"
else
  # Commands that should only run during
  # a CDE session
  MANPATH=/usr/dt/share/man:$MANPATH
  PATH=/usr/dt/bin:$PATH
fi

# More environment configuration…
export PATH=$PATH:$HOME/bin
export MANPATH
export PS1='$LOGNAME:$PWD> '
export VISUAL=vi
alias l="ls -al"
alias help=man
alias cd..="cd .."
alias cd...="cd ../.."

One advantage of this method is that you can define CDE-specific environment variables that won’t interfere with other logins, such as text-based or OpenLook logins. However, the VISUAL editing feature, like many commands in your .profile file, isn’t specific to any of these environments and is, in fact, desirable in all three. Given the fact that you don’t want to duplicate the code in your .profile file with similar code in the .dtprofile file, this technique maximizes your customization ability and simultaneously minimizes the amount of effort required.

A real-world example

The code shown in Figure A is an example of a .profile file you may actually use. If you log in to your system both with CDE and command-line mode (such as from a remote terminal), then you’ll probably want to have different, but similar, values for your PATH and MANPATH environment variables (among others).

First, we edited the .dtprofile file to uncomment the DTSOURCEPROFILE=true line. Please note that as you’re going through the .dtprofile file, you’ll see that Sun provides example code for making your .profile or .login file act differently in CDE mode.

Notice that the first thing we did was set up the base values for the PATH and MANPATH environment variables. These happen to be the values that we use for the command-line login. Then, our if statement contains two sections. If you’re in a command-line login, your shell executes the first section, which asks you for your terminal type, sets it up, and prints a welcome message. This would cause us problems if we executed it in CDE. The second section, executed only during a CDE login, adds the CDE commands to PATH and the CDE man pages to MANPATH. Finally, we export the path and set up a few environment variables and some aliases.

Debugging

You need to be careful when you edit your .dtprofile, .profile, and/or .login files. If any of these files contain errors, CDE may not allow you to log in. Luckily, it’s easy to recover from this sort of error. You simply select a command-line login from the CDE login screen (or log in as the root user if the changes in .profile prevent you from logging in using your account), then correct any mistakes in your startup files.

If you’re making some complicated changes, it may be easier to extract the section that you want to change into another file. You can then edit this test file and execute the file to test the changes. Once the changes are working correctly, you can put them back into the appropriate startup file. In the Korn shell, you use the . command to execute the test file, while you use the source command to do so in the C shell.

Conclusion

When you switch back and forth between X terminals and dumb terminals, you should spend a little time customizing your startup files to make your life simpler. Here, we showed you how the CDE .dtprofile file and your shell’s startup file (.profile or .login) interact.

Alvin J. Alexander is an independent consultant specializing in UNIX and the Internet. He has worked on UNIX networks to support the space shuttle, international clients, and various Internet service providers. He has provided UNIX and Internet training to over 400 clients in the last three years.

[The Cobb Group Home Page]

Copyright (c) 1996 The Cobb Group, a division of Ziff-Davis Publishing Company. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of Ziff-Davis Publishing Company is prohibited. The Cobb Group and The Cobb Group logo are trademarks of Ziff-Davis Publishing Company.